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ABSTRACT 



A method of reserving resources in an internet is disclosed. 
The method provides an improved process for use in relation 
to large scale shared-tree multicast environments since its 
use results in a reduction in path state in the routers (A-E, 
R1-R6) in the internet. The method involves the sending of 
path characteristics upstream from receivers (H1-H7) to 
senders (H1-H7), the routers in between combining path 
characteristics from different sources downstream of them. 
Reservations are subsequently made on the basis of the 
combined path characteristic data, the nature of the sender's 
traffic and the end-to-end quality of service required by the 
sender. 

7 Claims, 3 Drawing Sheets 
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PACKET NETWORK 
BACKGROUND OF THE INVENTION 

The present invention relates to a method of reserving 
resources in a packet network. It has particular utility in 
relation to providing an internet offering Quality of Service 
guarantees. 

Methods of reserving resources in an internet are well 
known. The method which is currently best supported in the 
Internet is that defined by the Resource Reservation Protocol 
(RSVP) 

There is a desire to enable an internet to provide real-time 
communication as is, for example, required if telephone 
conversations or video-conferences are to be conducted over 
it. In this regard, two qualities of service that might be 
provided have been specified by the following documents 
(which are incorporated herein by reference): 

(1) S. Schenker, C. Partridge, R. Guerin. Specification of 
Guaranteed Quality of Service, Request For 
Comments, September 1997, RFC 2212; and 

(2) J. Wroclawski. Specification of the Controlled-Load 
Network Element Service, Request For Comments, 
September 1997, RFC 2211. 

Essentially, Guaranteed Service as defined in the first 
document allows a user to specify an upper bound on the 
time taken for his message to reach a recipient, whereas 
Controlled Load Service offers a service qualitatively simi- 
lar to that provided by the internet when it is only lightly 
loaded. Operating an internet in accordance with the RSVP 
protocol allows the provision of real-time communication. 
The provision of such communication to the above- 
mentioned Quality of Service classes when operating an 
internet in accordance with the RSVP protocol is discussed 
in the following document (also incorporated herein by 
reference): 

(3) P. White. RSVP and Integrated Services in the Inter- 
net: a tutorial, IEEE Communications magazine, May 
1997. 

In an internetwork operating in accordance with the RSVP 
protocol, a sender which wishes to increase the level of 
traffic it is sending to one or more receivers first sends out 
a path information packet which contains information con- 
cerning the characteristics of the path along which it has 
travelled and also information specifying the increased 
traffic level. This passes through each of the nodes through 
which the sender's increased traffic will pass in travelling to 
the one or more receivers. Path characteristic data is 
installed at those nodes as a result of the packet passing 
through them. Once this process is complete the one or more 
receivers calculate a required reservation on the basis of the 
increased traffic specification and end-to-end path charac- 
teristics (obtained from the received path information 
packet) and send a packet back towards the sender specify- 
ing the reservation required. Provided sufficient network 
resources are available each node receiving the reservation- 
requesting packet reserves appropriate resources and for- 
wards the packet back towards the sender. 

When an internet is operated in accordance with RSVP, 
receivers are responsible for requesting the reservation of 
resources. In contrast, in an internet operating in accordance 
with the Internet Stream Protocol Version 2 (ST2), senders 
are responsible for requesting reservation of resources. 

Although a network operating in accordance with ST2 
allows resources to be reserved more quickly than is pos- 
sible with RSVP, it does not allow for different levels of 
service to be provided in relation to a single one-to-many or 
many-to-many communication. 
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SUMMARY OF THE INVENTION 

According to the present invention there is provided a 
method of reserving resources in a packet network compris- 
ing a plurality of hosts and one or more interconnecting 
nodes, said method comprising the steps of: 

operating a plurality of receiver hosts to send reverse - 
routed packets, containing one or more reservation 
influencing parameters, along a route via one or more 
1Q of said interconnecting nodes to one or more sender 
hosts; 

operating said one or more intermediate nodes to: 
combine one or more parameters of received reverse - 
routed packets from different receivers to generate 
15 combined reservation influencing parameters; 

store said combined parameters; and 
send a reverse-routed packet containing said combined 
parameters further along said route towards said 
sender hosts; 

20 operating said sender hosts to send a resource reserva- 
tion packet to one or more receivers back along said 
route; and 

operating said one or more intermediate nodes, respon- 
sive to said reservation packet, to reserve resources 
2 5 in accordance with reservation influencing param- 

eters stored at that node. 
Because intermediate nodes examine reservation influ- 
encing data sent by receivers, and reserve resources 
accordingly, the present invention better tailors a resource 
30 reservation to receivers' requirements. Furthermore, the 
present invention achieves this without sacrificing the faster 
resource reservation associated with sender initiated 
resource reservation protocols. 
Also, by combining path characteristic data in this way, 
35 the amount of path characteristic data sent between nodes in 
a network where a sender sends traffic to many receivers (i.e. 
where the sender is multicasting) is reduced. 

In some embodiments, said one or more reservation 
influencing parameters include an indication of a desired 
40 quality of service class, and said one or more intermediate 
nodes are operable to: 
update said parameters to represent the highest quality of 
service class requested by downstream receivers; and 
reserve resources in accordance with the resource reser- 
45 vation process associated with said highest quality of 
service class. 

In this way, it is possible to support different quality of 
service classes within a single one- to-many or many-to- 
many communication. For example, some receivers might 

50 request a quality of service in accordance with the Guaran- 
teed Service mentioned above, whereas others might only 
require a quality of service in accordance with the Con- 
trolled Load specification mentioned above. Thus, a more 
flexible set of services can be provided. 

55 In some embodiments the reservation packet carries infor- 
mation indicating the nature of the traffic being output by the 
one or more senders, and node takes that information into 
account in calculating the resources to be reserved. In 
applications where the traffic from a sender is of a prede- 

60 termined nature then this will not be essential. 

In preferred embodiments, routing between the hosts is in 
accordance with a shared-tree protocol. In situations where 
there are a plurality of senders this reduces the amount of 
reservation influencing data that need be stored at a node. 

65 This is especially advantageous in relation to communi- 
cations involving a large number of senders. A large number 
of senders might exist in video or audio conferences involv- 
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ing many people. Even greater numbers of senders are The internet operates in accordance with the TCP/IP 
possible in multi-player games or Distributed Interactive network architecture. In addition, at least the routers and 
Simulations. These potentially involve many thousands of computers shown in FIG. 1 support multicasting, 
hosts both sending and receiving messages. Each of the seven computers (HI to H7) is controlled by 
According to a second aspect of the present invention 5 a program which allows its user to participate in a multi- 
there is provided a packet network node comprising: player game. On a user acting to influence the game, a 
means for combining one or more parameters of received message representing his action is sent to each of the other 
reverse -routed packets to generate combined reserva- computers. As will be appreciated by those skilled in the art, 
tion influencing parameters; such a message will be routed in accordance with a multi- 
means for storing said combined parameters; 30 casting protocol, with the seven computers forming a mul- 
means for sending a reverse routed packet containing said ticast g rou P- ^ description below assumes that a source- 
combined parameters further along said route to said based tree multicast ™ting protocol is used, but a shared- 
sender hosts- and trec P rotoc °L sucri as trie Core Based Tree (CBT) protocol 
means for reserving resources in accordance with com- ^ m | ht J» used ^ ad ' J} 10 ** skOled in the art wiU have litUe 
bined reservation influencing parameters stored at that 15 f*, t ? n a ^ptmg the embodiment to operate m accor- 
node responsive to a reservation packet. dance Wlth a ^red-tree multicasting protocol. 
By way of example, specific embodiments of the present In accordance with Internet terminology, the computers 
invention will now be described with reference to the arc referred t0 below ™ hosts > and ^ word <node ' is 
accompanying drawings. intended to refer to both hosts and routers. Programs running 

20 on the computers are referred to as applications. Since more 

BRIEF DESCRIPTION OF THE DRAWINGS than one application requiring access to the internet may be 

FIG. 1 is an illustration of a group of computers commu- executable by any given host, each application is assigned a 

nicating with one another using an internet; 'P ort number' so that incoming messages labelled with a 

FIG. 2 is a schematic illustration of the contents of a port number can be passed to the corresponding application, 

reservation setting packet used in a first embodiment of the As those skilled in the art will know, the TCP/IP protocol 

present invention; su ite uses addresses which refer to interfaces rather than 

FIG. 3 is a schematic illustration of the contents of an n ° des - Hence the host HI is identified by the IP address for 

upstream-routed worst path characteristics per node packet ^ dllc * Iland ih * router Rl has one IP address for the 

used in the first embodiment; 30 interface via which it connects to the LAN LI and another 

™„ A . . .••«**• e ,u i_ address for the interface 13 by which it connects to the first 

FIG. 4 is a schematic illustration of worst path charac- su b n et SI 
teristics per path data stored in a node which operates in 

accordance with the first embodiment; and A me f sa g e L * said t0 l [ avel ? 0V ™ iTC * m fr° ma *nding 

FIG. 5 is a schematic illustration of worst path charac- h f t0 other h ° sts m the S™*- ^ this reason, 

teristics per interface data stored in a node which operates in 35 ^ hen disclosing the reserving of resources for a message 

accordance with the first embodiment. f ™ m > sa * fir fi st * ost ™ * ^^'^f^^ 

between the first router Rl and the first LAN LI is known 

DETAILED DESCRIPTION OF A PREFERRED as an upstream interface, and the interface 12 between the 

EMBODIMENTS first router Rl and the first subnet SI is known as a 

FIG. 1 shows seven computers (HI to H7), each of which 40 downstream interface, 

is connected to a Local Area Network (LI to L6) which also Broadly, according to a first embodiment of the present 

includes a gateway router (Rl to R6). Two of the computers invention, the portion of the internet serving the seven hosts 

H5, H6 are connected to a single Local Area Network (HI to H7) is operable in accordance with the TCP/IP 

(LAN), the other five computers are connected to respective network architecture but is additionally operable in accor- 

LANs, The gateway routers (Rl to R7) are interconnected 45 dance with the following procedure to allow each of the 

by means of a network which comprises a number of subnets hosts to reserve resources of the internet resources the 

(SI to S6) connected to one or more other subnets by characteristics of the communication paths to the other hosts 

intermediate routers (A to E). can be controlled. For example, the delay in the communi- 

A first subnet SI connects three of the gateway routers cation can be minimised or reduced below a predetermined 

(Rl to R3) to a first intermediate router A, which is in turn 50 bound. 

connected via a second subnet S2 to a second intermediate In the embodiment, each host occasionally sends a Res- 
router B. A third subnet S3 connects the second intermediate ervation Packet (hereinafter an RES packet) to all the other 
router to third and fourth intermediate routers C,D. The third hosts. Part of the purpose of this packet is to provide each 
intermediate router C is connected via a fourth subnet S4 to node with the address of the downstream interface of the 
the fourth gateway router R4. The fifth subnet S5 connects 55 node directly upstream on the source -based tree which the 
the fourth intermediate router D to both the fifth intermedi- message follows to each of the other hosts. This address is 
ate router E and the fifth gateway router R5. The fifth known as a previous hop address. Those skilled in the art 
intermediate router E is connected to the sixth gateway will recognise that a similar function is performed by the 
router R6 via a sixth subnet S6. PATH messages of the RSVP protocol. 

The computers (HI to H7), routers (Rl to R7, A to E) and 60 Once a recipient host has received at least one RES 

subnets (SI to S6) form a portion of an internet. The internet packet, it will start sending Backwards Control packets 

includes a number of other computers (not shown) con- (hereinafter BWDC packets) towards the sending host, 

nected to the LANs (LI to L6) and might include further Normally, the recipient host will send one such packet in a 

subnets, routers and LANs. The internet is operable to allow predetermined refresh period (though in certain circum- 

the computers (HI to H7) to send messages to one another. 65 stances (to be described below), it will send more than one). 

It might, for example, be the network generally known as the Each of the nodes reads any BWDC packet it receives and 

Internet. stores worst path characteristic values included in the packet 
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in its memory. The stored values are then used to update data 
representing the worst per interface path characteristics 
(stored data like this is known as a 'state* entry to those 
skilled in the art). A similar worst per interface state entry is 
made in relation to each of any other downstream interfaces 5 
of the node. The state entries are then compared and the 
worst per node path characteristics are obtained from the 
state entries and included in a BWDC packet to be sent 
upstream. 

v If the contents of a BWDC packet to be sent upstream 30 
differ from the contents of the previous BWDC packet sent 
from the node, then the BWDC packet is sent immediately. 
Otherwise the BWDC packet is sent at the expiry of the 
refresh period. 

This procedure results in each of the nodes in the source- 35 
based tree storing a worst per interface state entry repre- 
senting the worst of all the path characteristics from paths on 
the tree leading from the node to one or more of the recipient 
hosts. 

20 

On the basis of any RES packet which is subsequently 
received, each node calculates the reservation required on 
each downstream link of the tree, using the corresponding 
worst per interface state entry. 

Any installed reservations or state entries in the node are 25 
implemented using so-called 'soft-state' as is used in RSVP. 
This means that the state entries will be deleted in the 
absence of appropiate refreshes known to those skilled in the 
art. 

The reservation process will now be described in more 30 
detail in relation to FIGS. 2 to 5. 

The RES packet sent from a sending host contains the 
information set out in FIG. 2. The packet is encapsulated in 
an IP datagram in a similar fashion to say, a RSVP control 
message, being identified as a datagram relating to the 35 
present reservation protocol by a next header field (not 
shown) in the IP header. Those skilled in the art will be 
familiar with other fields in the IP header not shown in FIG, 
2. 

The other fields in the RES packet contain the following 4Q 
information. 

Session — this is identical to the session field defined by 
the RSVP protocol — it includes the destination address (a 
multicast address for the multicast group) for the flow (i.e. 
one or more messages) to which the RES packet relates and 45 
other parameters relating to the flow. The nature of these 
parameters is known to those skilled in the art 
Sender Template — this is identical to the corresponding field 
defined by the RSVP protocol — i.e. it is a filter specification 
identifying the sending host. It contains the IP address of the 50 
sending host and optionally the sending host port being used. 
Traffic specification (Tspec) this is identical to the corre- 
sponding field defined by the RSVP protocol describing the 
sending host's traffic characteristics using the following 
token bucket representation. 55 

p=peak rate of flow (bytes/second) 

b-bucket depth (bytes) 

r-token bucket rate (bytes/second) 

m-minimum policed unit (bytes) go 

M=maximum datagram size (bytes) 
Previous hop (Phop)— this is identical to the corresponding 
field defined by the RSVP protocol i.e. it is an object 
including the previous hop address. 

Timestamp field — this is stamped with the time of the local 65 
node clock just before being forwarded to the next node(s) 
down the distribution tree. 



End-to-end delay field — this gives the current delay from 
when a packet was transmitted by the sending host until it is 
due to arrive at the upstream interface of the next node. 
CRTs field(2 bits) — this identifies the ceiling reservation 
type of the sending host application. 11 indicates guaranteed 
service, 10 indicates controlled-load, and 00 indicates best- 
effort. 01 is currently unspecified although may at some time 
be used for a new service with quality in between best-effort 
and controlled-load. 

QoSvoid bit — if set to one this indicates that no quality of 
service guarantees can be offered. 

If the sending host requires Guaranteed Service then the 
datagram further contains a Guaranteed Service Object 
which includes the following information. The values Csum 
and Dsum are as defined in the Guaranteed Service speci- 
fication mentioned above. 

CSum — accumulation of C values since last upstream 
reshaping point. 

DSum — accumulation of D values since last upstream 
reshaping point. 

Desired delay bound field which indicates the end-to-end 
delay bound desired by the sending host application. 
Accumulated delay bound field which indicates the installed 
delay bound between sending host and the upstream inter- 
face of the next node. 

Delayvoid bit (If set, this bit is an indication to any recipient 
host that the desired delay bound cannot be guaranteed). 
Lossvoid bit (If set, this bit is an indication to the recipient 
host that a loss-free service cannot be guaranteed). 

The BWDC packets transmitted by each node and the 
recipient hosts running under control of the application are 
illustrated in FIG. 3. Like the RES packets, the BWDC 
packets are encapsulated in an IP datagram. The destination 
IP address is in each case the previous hop address. Those 
skilled in the art will realise that, in that aspect, the BWDC 
packets are like the RESV packets of the RSVP protocol. 

The other information contained in the BWDC packet 
includes: 

Session — this is identical to the session field defined above 
for the corresponding RES packet. 

Downstream hop object — this is identical to RSVP next hop 
object — i.e. it gives the address of the upstream interface of 
the node directly downstream that sent the packet. 
Timestamp field which is stamped with the time of the local 
node clock just before being sent to the node directly 
upstream. 

Timedeltaprev field — this is filled in with the stored value of 
timedeltaprev (whose value is explained below) just before 
being sent to the node direcdy upstream. 
CRTr field(2 bits). This field indicates the recipient host 
application ceiling reservation type. The mapping between 
the values of this field and the reservation types they 
represent are the same as for the CRTs field in the RES 
message. 

Worst Case Delay field. This equals the maximum data 
packet propagation delay measured between the upstream 
interface of the node from which the BWDC packet was sent 
and each recipient host downstream of that node. 
Path MTU field. This equals the minimum pathMTU value 
between the upstream interface of the node from which the 
BWDC packet was sent and each recipient host downstream 
of that node. 

Worst Case Ctot field — this is as defined in the Guaranteed 
Service specification — i.e. it equals the maximum accumu- 
lated Ctot value along the paths between the upstream 
interface of the node from which the BWDC packet was sent 
and each recipient host downstream of that node. 
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Worst Case Dtot — this is as defined in the Guaranteed 
Service specification — i.e. it equals the maximum accumu- 
lated Dtot value along the paths between the upstream 
interface of the node from which the BWDC packet was sent 
and each recipient host downstream of that node. 
Path bandwidth This equals the maximum path bandwidth 
value along the paths between the upstream interface of the 
node from which the BWDC packet was sent and each 
recipient host downstream of that node. 
Sender address — set to the address of the sending host — the 
address (in combination with the multicast address of the 
group of hosts HI to H7) indicates to the node which 
source-based tree relates to the packet. 

Qot and Dtot are as defined in the Guaranteed Service 
specification. Where the sending host has requested Guar- 
anteed Service the BWDC packet additionally includes the 
following: 

Excess delay field — the amount by which the installed 
end-to-end delay bound currently exceeds the desired end- 
to-end delay bound. 

Bottleneck flag — as explained below, if set to 1 this indicates 
that the BWDC message has travelled at least as far as the 
bottleneck router (i.e. the router where the accumulated- 
bound first exceeded the desired-bound on the first pass of 
the RES message) 

On setting up the reservation initially, each host transmits 
an RES packet to the other hosts. Each node on the source - 
based tree made up by the paths from the sending host to the 
recipient hosts carries out the following timing operations. 
As explained below, each node carries out these operations 
each time a RES packet is received. 

Firstly, the timestamp field is read and compared to the 
node's local clock to determine the time it has taken the RES 
packet to traverse the last hop. This duration is stored at the 
node as the parameter timedeltaprev. The timestamp is then 
set in accordance with the node's local clock and the RES 
packet is sent onwards to the next node(s) along the source- 
based tree towards the recipient hosts. This process is 
repeated until each of the nodes involved store a parameter 
(timedeltaprev) representing the propagation delay over the 
hop directly upstream of them (when traversed in the 
downstream direction). 

Once the RES packets have propagated through the nodes 
of the source-based tree, each of the recipient hosts sends a 
BWDC packet towards the sending hosts. The initial values 
placed in the packet by the hosts are determined as follows. 
The path MTU, and path bandwidth correspond to the 
characteristics of the LAN to which the sending host is 
attached. The host inserts its IP address in the downstream 
node field and sets CRTr in accordance with the quality of 
service it requires. The worst case path characteristics are all 
set to zero, as is the bottleneck flag. The excess delay field 
is unused at this stage. The timedeltaprev parameter is 
assigned to the timedeltaprev field. 

On receipt of a BWDC packet a node carries out timing 
operations and worst per node path characteristic determin- 
ing operations as described below. 

The timing operations involve the node first reading the 
timedeltaprev field in the packet. It will be realised that this 
records the propagation delay (experienced by the RES 
packet) over the hop downstream from the node (when 
traversed in the downstream direction). By also reading the 
timestamp field of the BWDC packet and the local clock a 
value for the propagation delay over the same hop in the 
other direction is obtained. It is assumed that the delay over 
the downstream hop is the same in either direction. Hence, 
by taking the average of these two delays a value of the 



propagation delay independent of any discrepancy between 
the node clocks is obtained. This average delay for the 
downstream hop is stored by the node as a parameter 
( dnext\ 

S The path characteristic monitoring operations are as fol- 
lows. 

Upon arrival of an BWDC packet, the node first checks 
for the existence of a worst per path state entry relating to the 
current session and to the downstream path identified by two 
10 path identifying parameters, namely the downstream node 
field of the packet, and the address of the downstream 
interface on which the BWDC message arrived. 

If no previously stored worst per path state entry is found 
that relates to the path and session, then a new worst per path 
15 state entry is created. 

The format of a worst per path state entry is as shown in 
FIG. 4 and includes a session identifying field, and a sender 
address field, the two path identifying fields and additionally 
the following fields: 
20 Worst Case Ctot 

Worst Case Dtot 

Worst Case Delay 

path bandwidth 

25 CRTr 

pathMTU 
dnext 

bottleneck flag 

The new worst per path state entry is created by assigning 
30 the CRTr, path bandwidth, pathMTU, Worst Case Delay, 
Worst Case Ctot and Worst Case Dtot values contained in the 
BWDC packet to the corresponding fields of the worst per 
path state entry. The parameter dnext calculated in the 
timing operation is assigned to the dnext field. The bottle - 
35 neck flag is initialised to zero and is used as explained below. 
If the node has a plurality of worst per path state entries 
on the same interface and relate to the same session, then it 
combines them to create a worst per interface state entry. 
This situation might arise where the downstream interface 
40 connects to a shared medium LAN. 

As shown in FIG. 5, the worst per interface state entry 
contains the same fields as the worst per path state entry save 
that it lacks the downstream node field. The values assigned 
to the session, sender address field and downstream interface 
4 5 fields are those of the worst per path state entries. The values 
for the other fields are calculated as follows. 
Worst Case Ctot=MAX{Worst Case Ctot,} 
Worst Case Dtot«=MAX{Worst Case Dtot £ } 
5Q Worst Case Delay«MAX{Worst Case Delay,-} 
path bandwidth=MAX{path bandwidth,} 
pathMTU-MINfpathMTU,} 
CRTr=M AX { CRT,} 
dnext-MAXjdnextJ 
55 where the subscript i takes values from 1 to the number of 
nodes sharing the downstream interface. It will be seen that 
the values Worst Case Ctot, Worst Case Dtot and Worst Case 
Delay that are stored in the worst per interface state entry are 
worst case path characteristic values for the downstream 
60 interface. It is possible that the values relate to different 
paths from the interface. The bottleneck flag is set to one if 
any of the per path state entries have it set to one. 

Having created a worst per interface state entry for each 
of its downstream interfaces, the node then generates a 
65 BWDC packet containing worst per node data at least once 
every refresh period. The parameters to be included in the 
worst per node data are calculated as follows 
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Worst Case Ctot=MAX{ Worst Case Ctot„+Clocal„} where 
Clocal„ is the value of Ctot between the downstream inter- 
face on which the BWDC packet arrived and the upstream 
interface (determined by the session) of the node; 

Worst Case Dtot=MAX {Worst Case Dtot^+Dloca^} 
where Dlocal„ is the value of Ctot between the down- 
stream interface on which the BWDC packet arrived 
and the upstream interface (determined by the session) 
of the node; 

Worst Case Delay=MAX{Worst Case Delay„}+dnext M 

path bandwidth=MIN(MAX{path bandwidth,,}, path 
bandwidth upstream) 

CRTr=MAX{CRTr„} 15 

pathMTU«MIN(MIN{pathMTU n }, pathMTU upstream) 
where n is an index which takes values from one to the 
number of downstream interfaces from the node and 
'pathMTU upstream* and 'path bandwidth upstream' 2 o 
represent the minumum packet size and the band- 
width of the upstream hop respectively. 

If CRTr is not set to 11 then Ctot, Dtot and Worst Case 
Delay are set to zero. 

The above operations are repeated by each node in the 25 
source-based tree relating to the current session. It will be 
realised that for a flow from a given sending host, each node 
stores the worst case characteristics of all the paths leading 
from the node to the recipient hosts. 3Q 

The sending host then sends a further RES packet (FIG. 
2) requesting, for example, Guaranteed Service. Hence, the 
CRTs field in the packet is set to 11 and the desired delay 
bound is set to the limit that the receiver wishes to be placed 
on the time taken for a packet from the sending host to reach 35 
all the recipient hosts. 

The Traffic Specification fields are filled in by the sending 
host, and the end-to-end delay field is set to the value of the 
parameter dnext stored at the sending host. Each of the fields 
of the Guaranteed Service other than the desired delay 40 
bound is initialised to zero. 

At the first node downstream along the source-based tree, 
the queuing delay to be imposed on the flow in relation to 
each of the one or more downstream hops involved in the 
current session. This is determined in accordance with the 45 
equation below: 



Equation (1) 



50 



The Worst Case Delay value equals the sum of the 
corresponding field and the dnext parameter of the worst per 
interface state entry at the current node. At the first node the 
accumulated bound will normally be zero or negligible. The 
Qdelay value represents an estimate of the total queuing 55 
delay that can be tolerated over the remainder of the path to 
a recipient host. 

Processing similar to that carried out by receivers oper- 
ating in accordance with the RSVP protocol is then used to 6Q 
calculate a bandwidth to be reserved on each of the down- 
stream hops in order to stay 'on-course' for the desired 
bound. This calculation will often be an overestimate 
because it may be that the individual worst per interface 
parameters relate to different paths from that interface. 65 
Those skilled in the art will realise that the estimate is 
calculated using the following equations: 
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Qdelay = 

(b-M)(p-R) (M + Ctot) 
___+ - 



Equation 2 



+ Dtot (case p> R> ~r) 



Qdelay m 



Equation 3 



(Af + Ctot) 



+ Dtot (case R > ~ p > - r) 



The parameters M, p, b and r are obtained from the 
corresponding fields of the RES message (the meaning of 
those symbols is as set out above in relation to the RES 
message). The values of Ctot and Dtot are a sum of the 
values from the worst per interface state entry relating to the 
current downstream interface and the local values of C and 
D. To obtain the value of Qdelay to insert into the equations 
2 and 3, equation 1 is used. The equation is solved to yield 
a value for R and a bandwidth R is reserved over the hop 
leading from the current downstream interface. 

In accordance with the rules set out in the Guaranteed 
Service specification, the values of CSum and DSum are 
used along with other parameters to calculate the amount of 
buffering that must be assigned to the reservation to prevent 
packet loss. 

Once the reservation request has been serviced the end- 
to-end delay field in the RES packet is increased by adding 
to it the following: 

The propagation delay, dnext for the next hop 
An estimate of the current local queuing delay(for the 
relevant outgoing interface) for data packets of the flow 
to which the RES packet refers. 
The following updates are also made to the RES packet: 
The accumulated-bound field of the copied packet is 
increased by: 

1) The propagation delay, dnext for the next hop, and 

2) The installed local queuing delay bound (for the 
relevant downstream interface) for messages of the 
flow to which the RES packet refers. This local 
queuing delay bound is obtained by inserting the 
reserved value of R into Equation 2and Equation 
3along with the local values C and D for the param- 
eters Ctot and Dtot respectively. 

The following updates are then made to the RES packet 
the local value of C is added to the CSum field 
the local value of D is added to the DSum field unless 
re-shaping of the sending hosts traffic is carried out at 
the downstream interface, in which case both CSum 
and Dsum are set to zero. 
Also, the Qosvoid field is set to one if either 

a) a Guaranteed Service reservation attempt fails to 
reserve a bandwidth at least as great as the token bucket 
rate of the traffic specification; or 

b) a Controlled Load reservation attempt fails. 

If a node receives a RES packet with Qosvoid set to one, 
then if MIN{CRTs,CRTr}is 10 or 11 it attempts to secure a 
Controlled Load reservation. 

Once updating of the fields is complete the timestamp 
field is (as described above) set equal to the local clock 
before forwarding the RES packet to each next hop down the 
routing tree. 

Similar processing is carried out at each of the subsequent 
nodes, the increase of the accumulated bound by the 
installed queuing delay resulting in the value of Qdelay 
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obtained from equation (1) continuing to be an estimate of 
the total queuing delay that can be tolerated for the remain- 
der of the path to a recipient host, Assuming the messages 
from the host to be in accordance with the declared traffic 
specification, and provided each of the nodes is able to 
reserve the calculated bandwidth R, the above-described 
processing at the nodes will be effective to enable messages 
from the sending hosts to be delivered within the desired 
delay bound to all of the recipient hosts. 

If any node is unable to reserve the bandwidth as calcu- 
lated above then (subject to policy configurations at the 
node) as much bandwidth as possible is reserved. If, 
however, the amount of bandwidth reserved is less than the 
value of the token bucket rate field of the RES packet then 
Guaranteed Service is not offered and this is indicated by 
setting the delay void, lossvoid and Qosvoid flags to 1. 

If the bandwidth reserved is more than the value of the 
token bucket rate field of the RES packet, then the accumu- 
lated bound is compared to the desired bound. 

Where the desired bound is higher then the reservation 
process continues as above. Since the reserved bandwidth R 
may be overestimated as explained above, this often results 
in the setting up of reservations which provide a delay over 
the end-to-end path which is less than the desired delay 
bound. 

Where, however, the desired bound is lower, the node 

sets a reservation bottleneck flag associated with the 
relevant per interface state entry, thereby labelling itself 
as a bottleneck node. 

sets the delayvoid flag in the RES packet to one and 
forwards it to nodes further down the tree. 

Where a node receives an RES packet with the delayvoid 
field set to one, it reserves the maximum bandwidth possible 
(perhaps limited to a multiple of the peak rate of the sending 
host) and forwards it on. 

On receiving an RES packet with delayvoid field set to 1 
and delayloss field set to 0(for CRTs-CRTr-11) the recipient 
host calculates the amount by which the accumulated delay 
bound field exceeds the desired delay bound field. The 
recipient host then immediately sends a BWDC packet with 
the excess delay field set to the calculated excess delay and 
with the bottleneck field set to zero. Each node receiving 
such an BWDC packet ignores the packet unless the bottle- 
neck flag of the node's associated worst per interface state 
entry is set to 1. The bottleneck node receives the BWDC 
packet and sets the bottleneck field to one. The node 
attempts to eliminate or reduce the excess delay indicated in 
the BWDC message by increasing the local bandwidth 
reservation. Following this if excess delay still exists the 
BWDC packet with the modified value of excess delay is 
then sent a hop at a time towards the sender with a 
reservation increase being attempted at each node until 
either the BWDC packet reaches the sender or the excess 
delay is eliminated. 

In the above embodiment, data is combined at a node and 
sent to a node upstream where that combined data is used to 
calculate an appropiate resource reservation. 

In other embodiments the resource reservation might be 
calculated on the basis of combined data at the node where 
the combination takes place. 

A second embodiment is similar to the first embodiment 
but uses a shared tree protocol. In the second embodiment 
the sender address field (in the BWDC packet, the worst per 
path and worst per interface state entries) is riot required. 
This is because the interfaces out of which the RES packet 
are to be sent are determinable by the node on the basis of 
the session parameter and the incoming interface. Since, 
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when using a shared tree the worst per interface state entries 
will relate to the multicast group rather than a specific sender 
to the multicast group, the number of worst per interface 
state entries in each node is only as great as the number of 
outgoing interfaces from the node. 

It will be seen how, in multi-sender environments, the 
second embodiment reduces the amount of worst per inter- 
face state entries required in comparison with known reser- 
vation protocols. 

In the above embodiments, the worst-case merging of C 
terms (e.g. Ctot), D terms (e.g. Dtot) and link propagation 
delay was carried out for each term independently. This 
results in an overly conservative local bandwidth reserva- 
tion. In preferred embodiments, a rate independent delay 
parameter which includes both the D term and the link 
propagation delay is used. This might be done by taking the 
forwarded value of D as the value from the worst case rate 
independent delay parameter rather than simply the maxi- 
mum D value from each path. 

It will be seen how the above embodiments enable a 
router to find the highest quality of service requested by any 
one of the downstream receivers. Similar considerations 
apply to path characteristic data and other reservation influ- 
encing parameters. It is the combination of such parameters 
at intermediate nodes in the network that allows a more 
flexible resource reservation to be provided for multicast 
communication in a packet network. 

What is claimed is: 

1. A method of reserving resources in a packet network 
comprising a plurality of hosts and one or more intercon- 
necting nodes, said method comprising the steps of: 

operating a plurality of receiver hosts to send reverse - 
routed packets, containing one or more reservation 
influencing parameters, along a route via one or more 
of said interconnecting nodes to one or more sender 
hosts; 

operating said one or more intermediate nodes to: 
combine one or more parameters of received reverse - 

routed packets from different receivers to generate 

combined reservation influencing parameters; 
store said combined parameters; and 
send a reverse-routed packet containing said combined 

parameters further aloog said route towards said 

sender hosts; 

operating said sender hosts to send a resource reserva- 
tion packet to one or more receivers back along said 
route; and 

operating said one or more intermediate nodes, respon- 
sive to said reservation packet, to reserve resources 
in accordance with reservation influencing param- 
eters stored at that node. 

2. A method according to claim 1 wherein: 

said one or more reservation influencing parameters 
include an indication of a desired quality of service 
class; 

said one or more intermediate nodes are operable to: 
update said parameters to represent the highest quality 
of service class requested by downstream receivers; 
and 

reserve resources in accordance with the resource res- 
ervation process associated with said highest quality 
of service class. 

3. A method according to claim 1 wherein said one or 
more reservation influencing parameters include path char- 
acteristic parameters. 

4. A method according to claim 3 wherein said path 
characteristic parameters comprise one or more delay 
parameters. 
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5. A method according to claim 1 wherein said hosts 
communicate in accordance with a shared tree routing 
algorithm. 

6. A packet network node comprising: 

means for combining one or more parameters of received 5 
reverse -routed packets to generate combined reserva- 
tion influencing parameters; 

means for storing said combined parameters; 

means for sending a reverse routed packet containing said ]Q 
combined parameters further along said route to said 
sender hosts; and 

means for reserving resources in accordance with com- 
bined reservation influencing parameters stored at that 
node responsive to a reservation packet. ]S 

7. A method of reserving resources in a packet network 
comprising a plurality of hosts and one or more intercon- 
necting nodes, said method comprising the steps of: 

operating one or more receiver hosts to send path char- 
acteristic data packets, containing one or more path 
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parameters, along a route via one or more of said 

interconnecting nodes to one or more sender hosts; 
operating said one or more intermediate nodes to: 

process one or more parameters of received path char- 
acteristic data packets to generate updated path char- 
acteristic parameters; 

store said updated parameters; and 

send a path characteristic data packet containing said 
updated parameters further along said route to said 
sender hosts 

operating said sender hosts to send a resource reserva- 
tion packet to one or more receivers back along said 
route; and 

operating said one or more intermediate nodes, respon- 
sive to said reservation packet, to reserve resources 
in accordance with path characteristic data stored at 
that node. 
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